<html>
<head><meta charset="utf-8"><title>pre-rfc discussion: connecting --explain and compiler errors · t-compiler/wg-diagnostics · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/147480-t-compiler/wg-diagnostics/index.html">t-compiler/wg-diagnostics</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/147480-t-compiler/wg-diagnostics/topic/pre-rfc.20discussion.3A.20connecting.20--explain.20and.20compiler.20errors.html">pre-rfc discussion: connecting --explain and compiler errors</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="204378025"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/147480-t-compiler/wg-diagnostics/topic/pre-rfc%20discussion%3A%20connecting%20--explain%20and%20compiler%20errors/near/204378025" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ben <a href="https://rust-lang.github.io/zulip_archive/stream/147480-t-compiler/wg-diagnostics/topic/pre-rfc.20discussion.3A.20connecting.20--explain.20and.20compiler.20errors.html#204378025">(Jul 20 2020 at 00:52)</a>:</h4>
<p>I'm a relatively inexperienced end-user. Though this is something I'm sure has been discussed before, I couldn't find anything.</p>
<p>On running <code>rustc --explain &lt;EXXXX&gt;</code>, a generic code example going over the error  is presented. This presents an excellent theoretical and practical overview of Rust used in error, however it is left to the user to asosciate this with their specific use-case. Mapping the <code>--explain</code> output to the users use case incurs a cognitive load that could possibly be eased by the compiler itself.</p>
<p>Currently,  the content of <code>--explain</code>appears to be strictly defined by the error number. By taking information from the source of the error, the compiler could generate output that could be thought of as "super-detailed compiler error", or "Error explanation based on a specific instance of a compiler error" </p>
<p>For example, error <code>E0271</code> example looks like this:</p>
<div class="codehilite"><pre><span></span><code>trait Trait { type AssociatedType; }

fn foo&lt;T&gt;(t: T) where T: Trait&lt;AssociatedType=u32&gt; {
    println!(&quot;in foo&quot;);
}

impl Trait for i8 { type AssociatedType = &amp;&#39;static str; }

foo(3_i8);
</code></pre></div>


<blockquote>
<p>This is because of a type mismatch between the associated type of some<br>
trait (e.g., <code>T::Bar</code>, where <code>T</code> implements <code>trait Quux { type Bar; }</code>)<br>
and another type <code>U</code> that is required to be equal to <code>T::Bar</code>, but is not.<br>
Examples follow.</p>
<p>Here is that same example again, with some explanatory comments:</p>
</blockquote>
<div class="codehilite"><pre><span></span><code>trait Trait { type AssociatedType; }

fn foo&lt;T&gt;(t: T) where T: Trait&lt;AssociatedType=u32&gt; {
//                    ~~~~~~~~ ~~~~~~~~~~~~~~~~~~
//                        |            |
//         This says `foo` can         |
//           only be used with         |
//              some type that         |
//         implements `Trait`.         |
//                                     |
//                             This says not only must
//                             `T` be an impl of `Trait`
//                             but also that the impl
//                             must assign the type `u32`
//                             to the associated type.
    println!(&quot;in foo&quot;);
}

impl Trait for i8 { type AssociatedType = &amp;&#39;static str; }
//~~~~~~~~~~~~~~~   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
//      |                             |
// `i8` does have                     |
// implementation                     |
// of `Trait`...                      |
//                     ... but it is an implementation
//                     that assigns `&amp;&#39;static str` to
//                     the associated type.

foo(3_i8);
// Here, we invoke `foo` with an `i8`, which does not satisfy
// the constraint `&lt;i8 as Trait&gt;::AssociatedType=u32`, and
// therefore the type-checker complains with this error code.
</code></pre></div>


<p>The compiler error:</p>
<div class="codehilite"><pre><span></span><code>error[E0271]: type mismatch resolving `for&lt;&#39;r&gt; &lt;for&lt;&#39;s&gt; fn(seed::browser::url::Url, &amp;&#39;s mut seed::app::orders::container::OrdersContainer&lt;Message, _, _&gt;) -&gt; Model&lt;&#39;s&gt; {init::&lt;seed::app::orders::container::OrdersContainer&lt;Message, _, _&gt;&gt;} as std::ops::FnOnce&lt;(seed::browser::url::Url, &amp;&#39;r mut seed::app::orders::container::OrdersContainer&lt;Message, _, _&gt;)&gt;&gt;::Output == _`
  --&gt; src/lib.rs:21:5
   |
21 |     App::start(&quot;app&quot;, init, update, view);
   |     ^^^^^^^^^^ expected bound lifetime parameter, found concrete lifetime
   |
   = note: required by `seed::app::App::&lt;Ms, Mdl, INodes, GMs&gt;::start`
</code></pre></div>


<p>and the line of code:</p>
<div class="codehilite"><pre><span></span><code>    App::start(&quot;app&quot;, init, update, view);
</code></pre></div>


<p>When understanding the compiler error, and the explanation, there is a lot of information going on. There remains a gap, however, in clearly showing how the three groups of information/data come together.</p>
<p>What I would like to propose, is a way for the compiler to intelligently draw these three together. If we take the purpose of <code>--explain</code> to be that it eases the developers burden of understanding the root of the error, it currently provides an excellent reference. If, in addition to serving as a reference, it can also draw  concrete and explicit connections between the reference entry and the immediate problem at hand, the burden could be further reduced.</p>



<a name="209149702"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/147480-t-compiler/wg-diagnostics/topic/pre-rfc%20discussion%3A%20connecting%20--explain%20and%20compiler%20errors/near/209149702" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Esteban Küber <a href="https://rust-lang.github.io/zulip_archive/stream/147480-t-compiler/wg-diagnostics/topic/pre-rfc.20discussion.3A.20connecting.20--explain.20and.20compiler.20errors.html#209149702">(Sep 04 2020 at 23:24)</a>:</h4>
<p>I think this is a good idea, and it was the original intent behind <code>--teach</code>, but there are three reasons I didn't push that flag further:</p>
<p>1) The effort spent on making the normal error better makes it so that it minimizes the need to produce an "extended" version, as almost everyone benefits from the more verbose error (although the counterpart of <em>hiding</em> things could be interesting to explore)<br>
2) Depending on the error there might be multiple reasons for why we arrive to them. Over time, what we have been doing is create more and more targeted errors which helps on both the explanation in the index and the diagnostic being outputted<br>
3) Sometimes we just <em>can't</em> figure out what the underlying cause is because the compiler (at least currently) doesn't keep track of enough information to do so.</p>



<a name="209149716"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/147480-t-compiler/wg-diagnostics/topic/pre-rfc%20discussion%3A%20connecting%20--explain%20and%20compiler%20errors/near/209149716" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Esteban Küber <a href="https://rust-lang.github.io/zulip_archive/stream/147480-t-compiler/wg-diagnostics/topic/pre-rfc.20discussion.3A.20connecting.20--explain.20and.20compiler.20errors.html#209149716">(Sep 04 2020 at 23:25)</a>:</h4>
<p>But your proposal certainly fits the scope and intent of the project.</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>